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1. Introduction 

This document describes the overall UPnP AV Architecture, which forms the foundation for the UPnP AV 
Device and Service templates. The A V Architecture defines the general interaction between UPnP Control 
Points and UPnP A V devices. It is independent of any particular device type, content format, and transfer 
prptouoi. Ft supports a variety of devices such as TVs, VCRs, CD/DVD players/'jukeboxes, settop boxes, 
stereos systems, MP3 players, stilt-image cameras, camcorders, electronic picture frames (EPFs), and the . 
PC. The AV Architecture allows devices to support different types of formats for the entertainment 
content (such as MPEG2, MPEG4. JPEG. MP3, Window.^ Media Architecture (WMA), bitmaps (BMP),- 
NTSC, PAL, ATSC, etc.) and multiple types of transfer protocols (such as IEC-61883/i'eEE-1394 HTTP 
GET, RTP, HTTP PUT/POST. TCP/IP, etc.). The following sections describe the AV ArchitecturUhd ■ . 
how the various UPnP AV devices and services work logedier to enable vmoxis end-user scenarios. . 

2. Goals 

The UPnP AV Architecture was explicitly defined to meet the following goals: 

• To support arbitrary transfer protocols and conteht formats^ • - ■ 

• To enable the A V content to flow directly between devices without any intervention from the 
Control Point. 

• To enable Control Pointe to remain independent of any particular transfer protocol and content 
format This allows Control Points to transparently support new protocols and formats: 

• Scalability, i.e. support of devices with very low resources, especially memory and processing 
power as' weir M fii'n-fcatuiia ilcvicba. ' - • " . 



3. Non-Goals 

The LlPnP AV Architecture does nol enable any of the following: 

• Two-way Interactive Communication, such as audio and video conferencing. Internet gaming, eta 

• Access Control, Content Protection, and Digital Rights Management 

• Synchronized playback to mu Itiple ren dering devices. 

4. Overview 

In most (non-AV) UPnP scenarios, a Conb-ol Point controls the operation of one or more UPnP devices in 
order to aguoiiipliah the desired behavior. Although the Control Point is managing multiple devices all 
mteractions occur in isolation between the Control Point and each device. ITie Control Point coordinates 
the operation of each device to achieve an overall, synchronized, end-user effect The individual devices 
do not mteract directly with each another. All of the coordination between the devices is performed by the 
Control Point and not the devices themselves. 
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Figure 1: Typical UPnP Device Interaction Model 
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Figure. 2: UPnP AV Devi^e Interaction .Model 



Most AV scenarios involve tlie flow of (entertainment) content (i.e. a movie, song, picture, etc.) from One 
■device to otiothor. AE^shown in Figure 2, an AV Control Point interacts with two or more UPnP devices 
acting, as source and sink, respectively. Althopgb'. the Control Point coordinates: and synchronizes. the 
behavior of both devices, the devices themselves, interact with each, other using a non-tlPnP (:;'o{3t-K>f- 
■■ band")xominiJtnIcation protbcoL TTie Conirbi Point uses OPriP ;o initialize and configure both devices ^SO'-. 
tliat the. desired conteilt is .'transferred frpni one device to the oihef.:; However, ; since ihe:.comenr;,ls 
: transferred using an "oiit^of-band" transfer protocol, the Contrpl Point is ript directly involved m ihe actual 
■transfer of the content, TTiVControI Point con figures the de^'ices as needed, triggers' the flow of content;^ 
•tbRrfeei.'! otit nf the way. Thus, after the iransfer has begun. ih& Control Point can be disconnected-withoiit.' 
disrupting- the flow of content. In other Words,- the' core task (i.e.' transfernn^- the content) feontlnues to:. 
ftiiKtion even witli0ut the Contrdl Point present. 
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As described in the above scenario, three distinct entities are involved: the Control Point, the source of the 
media conlerit (called the "MediaServer"), and the sink for the content (calied rtie "MediaRenderer^'). 
Throughout the remainder of the document, all three entities are described as if they were independent 
devices on the network. Aldiough this configuration may be common (i.e. a remote control, a VCR, and a 
TV), the AV Architecture supports arbitrary combinations of these entities within' a single physical device. 
For example, a TV can be treated as a rendering device (e.g. a display). However, since most TVs contain 
a built-ui tuner, the TV can also act as a server device because it could tunc to a particular channel and 
send that content to a MediaRenderer (e.g. its local display or some remote device such as a tuner-less 
display). Similarly, many IVIediaServers and/or MediaRenderers may also include Control Point" 
functionality. ^ForoxnmplE, an MP3 Rendererwill likely have some Ul controls {e.g. q small display and. 
some buttons) that allow the user to control the playback of music. 



5. Playback Architecture 



control point 

(Ul Application) 




ModiaRenderor 



RfenaenngContTDi 



ConnectbnManager 
AVTransport 



Isochronous or Asychronous 
PusfiorPull 

Figure 3 

The most common task that end-users want to perform is to render (i.e. play) individual items of content on 
a specific rendering device. As shown in. 

Figure 3, a content playback scenario involves three distinct UPnP components: a MediaServer, a 
MediaRenderer, and a UPnP Control PoinL These three components (each with a well-defined role) work 
together to accomplish the task. In this scenario, the MediaServer contains (entertainment) content that the 
user wants to render (e.g. display or listen to) on the MediaRenderer, The user interacts with the Control 
Point's Ul to locate and select the desired content on the MediaServer and to select the target 
MediaRenderer, 

The MediaServer coiiiains or has uutuas to a variety of entErtainment content, eirher stored locally or stored 
on an external device that is accessible via the MediaServer. The MediaServer is able to access its content 
and transmit it to another device via the network using some type of transfer protocol. The content 
exposed by the MediaServer may include arbitrary types of content including video, audio, and/or still 
images. The content is transmitted over the network using a transfer protocol and data format that is that is 
understood by the MediaServer and MediaRenderer. MediaServers may support one or multiple transfer 
protocols and data formats for each content item or be able to convert the format of a given content item 
into another formats on the fly. Eicamplcs of a MediaServer include a VCR, CD/DVD player/jukebox, 
camera, camcorder, PC, set-top box, satellite receiver, audio tape player, etc. 
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■ The. MediaRenderer obtains content froiri a MediaServer. via network, Examples- of. a Medigltehderer;' 
indlide'.tv, stereo, network-enabled speakers, MPS .piayers, Electronic -Picture Frgrne ;(|Pr^!;.a;music.' 
Gbntrol.I.ed W^ter' fountain, etc. The type of content that' a MediaRenderer; can receive depeiids;; on' the: 
transfer prptdcols anddata formats that .it supports. Some Med laRenderers inay -only siip'pprt- otife type.'of - 
cpntent (e.g..' audio pr still images);'- where as other- MedjaRencierers may suppprt a wide yarldty'df cpnt^^t '. 

. including V id cOj audio,. stili imogefi- . " 

The Coritroi .Point coordinates and manages the operation of the MediaServer and: MediaRehderer■■,'ias• 
dirp.cted bj; the nser (e.g, 'play, stop, pause) in- order'tp accomplish the.desired task (e.g;;play "MyFaVprte^ 
mu^ic); ■ Addition ally, the Control. Point provides' the .Uior any) fo> the-ilser ro iriteract-wilh In.oMeritq- 

■ 'cbntrol the operatiqn of tlie'device(E) (e.gy to select the desired content).' The layout of ihe Cbntrbfppirtt^^ 
iil and the functionality th^t it exposes is- implementation dependeril.'and determined- solely by- tfie it^m 
Point's, OTanjifBchirer, Sorne evample.i of a Gonti-ol Point might jncludfl a::TV with.fi;.tradii;lonaV-reinma:. 
control br a wireless-PDA-Iike device with a small display. ' .'. '-■. . ' ■::' V -- ■•-vi' 

- Nol^fi': The above-descriptions . talk about devices "sending/reicBivifig content ,tt^^ \\om netwbti;:-" -'jh;..!- 
Uic.contcxtofthc. Ay Arehftccturc, this includes ppin't^lo-poiht connections .such i«i an R^^ 

used to connect a^VCRto a TV, ..The-AV.Architectiire-tr.eats-'this type of connection as a smali part'{e:gl'.' ' ' 
..segnient) pf ^e hdnie network,' -Refer to the Conneqtionjylanager Service Terhplate for more details;!;?]; ' 

A^.describeid at?ove, 'lhe-.AV Architecture consists of threedistinct components that.perfqm 

roles. -In some cases', thiese comppnents-Will exist as; separate, ihdivldiigl UPnP.devices,.HDwe-i/e'r,^^^^ '::';■ 

need not be- the case. Device inanufacturersiare free-tO:cambine any of thes^ logica! entities;,iiitb.;a single,; . 

■ physical device. In siich.cases, the individi«il.compbnei)t3''Qfthe5ie combo devicM.may iiitanSct with-eacfi;: . I 
other .using either- the stanldard -UPnP cbntrorprptocbis (e.g. SOAP over14TTP).br usirtg Spme p?iva^^^^^ :.. ' 
commnniciition mechanism. In eidiercase,^thefiinctipn of each logical '■; 
However, in the later case, since the commuiiicafibn between the [ogicalentities is privat?; th'e-iridi viduat 
components will not be able to conmunlcate with' other UPof" A V deVices Biatdo not implemehi: the"' ; 
private protocol.' ' ' ■ 

...Asshown in Figures, the.Conti^ol Point is the'only component that initiates 'LH^Pa^^^ The.Cpntrol 
Point requests to configure the M^diaServisr and MediaRenderer so that the desired content flows' from thU - ' 
. MediaSeryertot|i(sMediaRende^^^ 

- by feofh theMediaServsr and MediaRenderer), 1li.^-MediiiServef ahdMediaR^^^ 

QCtipna to the Control Pobil. Hovvovor, if heedad, th? MediaS'eryer Bnct/or MadiaRBndBrer'maytsbrid oyeiir C 
poKncktionsto the-Cpriti-orPop^^ ' ' ■ :'-' ;' . '.;- ; 

MediaServer'sMediaRenderer's internal stat^ ' ' - . ' - 

■ The MedtaSeryepa:nd MediaRendeiBrda not;pontro Howc.wer, In pnierW ■; 

..transfer the conteni.jthe.MediaS?ryer™d MediaRendef er yse W "out-^^ : 
.proto'pol tq directly';trapsrnttths content, •Th.e'Contrpl Point is not involved in the actual jtfansfer of ji/iy . 

■ conterif, jt'siniply confrgures die M^diaServer and MediaRenderer as-needed and initiates the transfer 'of 
-the .coiitent .piiee 'flie transfer' begiiis, 'the' CqQtToi''P(ifnt "gets out of llj'e way^ an'd is no longer, neede^d to ' '. ;'' 

.' cornplete the transfer. ' . ' ' .... . .-. N-._:.X: 

.Wowever, if desired. by tho user, the Control'Point 15 capabjepf control ling .the flow oftha content by. 
.; 'lihvpkjn'g varibus.AyTrarisport actions such as' Sto Ff, REW,,Skip, Scan; elo. ..i^ditionaliyi the-^ 

:'GotitnjI Point is aiso-^ebla to coh^ 
; Brightae^, ConWt, Volume, Bala^ 
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5.1. Media Server 

The MediaServer is used to locate content that is available v[a the home network. MediaServera include a 
wide variety of devices Including VCRs, DVD playera, satellite/cable receivers, TV tuners, radio tuners, 
CD players, audio tape players, MP3 players, PCs, etc, A MediaServer's prirrary purpose is to allow 
Control Points to enumerate (\.e, browse or search for) content items that are available for the user to . 
render. The MediaServer contains a CnntentDirectoryService. a Connection Manager Seivicei and an 
optional AVTransporl Service (depending on the supported transfer protocols). 

Some MediaServers are capable of transFemng multiple content items at the same time, e.g. a hard-disk- 
bastid auiJ to jukebox may be able to simultaneously sticain multiple audio fibs to tlic network, lii order to 
support this type of MediaServer, the Connect! onManager assigns a unique Connection ID to each 
"connection" (i.e. each stream) that is made. This ConnectionID allows a third-party Control Points to 
•obtain information about active connections of the MediaServer. 



5.1.1. Content Directory Service 

This service provides a set of actions tliat allow the Control Point to enumerate the content that the Server 
can provide to the home network. The primary action of this service is BrowseQ- This action allows 
Control Points to obtain detailed information about each Content Item that the Server can provide. This 
infonnation (i.e. meta-data) includes properties such as its name, artist, date created, size, etc. 
Additionally, the returned mela-data identifies the transfer protocols and data formats that are supported by 
the Server for that particular Content Item. The Conft-ol Point uses this information to determine if a given 
MediaRenderer is capable of rendering that content in its available format. 

5.1.2. ConnectionManager Service 

Tliis service is used to manage the connections associated with a particular device. Tlic primaiy action oV 
this service (within the context of a MediaServer) is PrepareForConnectionQ. When implemented, tliis 
optional action is invoked by the Control Point to give the Server an opportunity to prepare itself for an 
upcoming transfer. Depending on the specified transfer protocol and data format, this action may return 
the InstancelD of an AVTransport service that the Control Point can use to control the flow of this content 
(e.g. Stop, Pause, Seek, etc). As described below, this InstancelD is used to distinguish multiple (virtual) 
instances of the AVTransport service, each of which is associated with a particular connection to Renderer. 
Multiple (viitual) instances of the AVTransport service allow the MediaServer to support cuultipte 
Renderers at the same time. When the Control Point wants to terminate this connection, it should invoke 
the MediaServer's ConnectionComplcteO action (if implemented) to release the connection. 

If the PrepareForConnectionO action is not implemented, the Control Point is only able to support a 
single Renderer at an given trnie. In this case, the Control Point should use lnstancerD=0. 

5.1.3. AVTransport Service 

This (optional) service is used by the Control Point to control the "playback" of the content that is 
associated with the specified AVTransport. This includes the ability to Stop, Pause, Seek. etc. Depending 
on the supported transfer protocols and/or data formats, a MediaServer may or may not Implement this 
service. If supported, the MediaServer can distinguish between multiple instances of the service by using 
the InstancelD that is included in each AVTransport action. New instances of the AVTransport service 
are creuled via the ConneciionMunuger's PrepureFurCunnectlonO- A new Instance Id is allocated for 
each new Service Instance. 
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5.2, IWedlaRenderer 

The.MediaRenderer is used to render (e.g. display and/or listen to) content obtained Jroin;the.hame . , 
network, tliis inclufies 3 wide variety of devices inc)u{iing TVs, sWos, speakersVhaha^heid; auditf : 
■players, ..rriusiG'iCOntrolled vvater-fountiJiri,- etc- Its main feature is tiiat iti allows tlie 'Gohtrol PoinVto'-coiitco!. 
!iDw/cbntciit is rendered (e^. Drightiicss^;;CpnlTa5l, y Mutc^ etc), rAdditiohajiyr ficpcndins ori tjiis 

tTansferpr;otocprthat ii being usfed to o.btkin the eontent ftoin the netwbrk,,the jilediaRenderer ftiay ajsb-: !■ , 
allow the user to cqntrdl the flow of tHecjontent (e;g. Stop,;Pause,: Seefcj etc),- ^The MedjaRendereV ihcifudes 
a/llendenng Cpntrpl..Se|vice;B GonnecCionMariager Service, and, an dptjoria! AVThnspprt S'^fee'O' ' ' 
(dep'ciniiing -onr-which- transfer (»dtOcols°n« s;ii^)0j4e<!).--'" " .' •■ !'* 

■In order to support rervdering devices that are capable of handling multiple content items at th^ same, tirne 
(e.gi.art aadto riiixersuch as a Karaoke. device), the^Rendering Gontroi and AYtra'nspar{-Servic'es contain'^ ; 
multiple independent (Ipgiciil) instpiipes of these-seryices. ' ;Eacli-.(logical)--fnstaii6e dnjjiesj&seh'iG'eijis.-t/*:^^^ 
bound to a particular IriTOmJiis corindtioh. this . allows .the Contrbj; Point to control eac^^ 
independently frorn each, other. ' '' ' ' ■ ; • 

. rrfiiltiple logical instances of these. services are distinguished by a unic}ue:' InstanceID;: whichiTeferencas 
the ibgical instance. Each actipii invoked tiy-the 'Contrctl Pqjnt contains the Instmice:iD'iKal.- jlearitifies th 
correct instance;. ' " ' ' ' ' ' . • • ' ' ■ ^ y . 



5.2.1. RbhderingCoritrolSeryice 

This service provides ..a set of actions that allow the .Control Pflint'tb contfol'how the.llenderer renders a '-/-^ 
piece- of mpoming content. This 'includes: rendering cliaracteristics .sui^^as Bh'^tness,' Gdiiir^t^ Yblumei \:f<. 
. Mute,i etc.' 'The Rendering Con& 

to--*in»x together"' one or mpre crintent itfini.s (e:e. a Pjctiire-ln-Picmrft wiridow nn a TV'oran.iiiidiolir^iieir - - ■ 

device]!. New' instanQCSof the service are created by the.ConnectionManage'r's PrepareFbfebh 

action. ■ . ' '■ ' : '■ ' ''yy '' 

5.2.2. ConnectipnManagerService 

Tlns service is .used to mpnage the connections assckia^^^ : . ' | ■ 

Mcdialicndcrcr, thc priinaty action .of this scrviet 'is the GctProto.qolIhfoO pcti6n- Th.i? pcHbri iillowfl'^d ' ■ : 
Contrpi Poirtt.tp enunierate th.E transfer protocols and data fdrmats that are supported by ihe, " ' J't, •• 
MediaRenderer, This inforTnatibn: i^ used to pre.detennine if a KlediaRenderer is'capableidf renderirig-,a' : 
^specific content; iteTTi. A MediaRenderer may also-implement the bptionai'-PrepareForCbiiMcfipnO ' i;. " 
-action.'^; This actloti'.is i.nvQked by the Control Point tp give the^Render an opportunity' to prepare -ite'elf-fe.r^ 
an upcoming transfer. Additionally, this.action assigns a ^unique Connection ID thatcanbeused by a-S'^-: i^J- 
party Corjtrol Point to pbtairt infotTnatip'n abbUt'the tbnnecttons that the JvtediaRenderet is using;'- Also;? ■ ,r 
.depending: on Ihc 'spccificd transfer protoco! arid' data formot being uao'd, this action may return' ^, y piiq'ue : r'. 
AVTraiisport-lhstanceiD that the Cdntrof Point' can. jise tot coritrol iJie flow'of the content (evg;= StGp,:-P&C, 
Seek,.etc), (Refer tothe. A VTranspprt section' below fonaM^ ' .. '-v' ^i;/" I 

■PrepareFprConnectionO also.returns a unique-Rendering Conlrol Insrtanceip which- can be uscd by thV ' 
Gontrdi Point to cpntrbi the rendering characteristics-oiFlhe associated pori'tent as desbribed.pboVe. 'wh'^iiii^ 
ihe ContToTPoinVwants'tb termipatp a connection^ it should invoke ihfe'Kert^derei^-sCpniil^ 
Wiori (ifimpiemehtHd) lb release the ppiihec^^^^^ - ' ' ■ ■ ■ '-' 
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5.2.3. AVTransport Service 

This (optionaO service is used by the Control Point to control the flow of the associated content. This 
incJudes the ability to Play, Stop, Pause, Seek, etc. Depending on transfer protocols and/or data formats 
that are supported, the Renderer may or may not implement this service, fn order to support 
MediaRenderers that ran simultaneously handle multiple content items, the AVTransport service may 
support, inultiple logical instances of this service. As described above, AVTransport InstancelDs ate 
allocated by the ConnectionManager's PrepareforConnectionQ action to distinguish between multiple 
service instances. . . 



5.3. Control Point 

Control Points coordinate the operation of the MediaScrver and tiie MediaRenderer, usually in response to 
user Interaction with the Control Point's Ul. The following describes a generic Control Point algoriftm : 
that can be used to internet with a wide variety of MediaServer and MediaRenderer implementations. 

1 • Discover AV Devices: Using UPnP's Discovery mechanism. MediaServers and MediaRenderere 
in the home network are discovered. , 

2. Locate Desir ed Content; Using the Server's ContentDirectory:;BroijvseO or SearchQ actions, a 
desired Contwit Item is incated. The information returned by BrowseO/SearchQ includes the 
transfer protocols and data formats that the MediaServer supports to transfer the content to the 
home network. 

3. Get-Rcnderer's-Sup aurtc J-Pro tocpls/Fali iii a taV Ushf^ rli e foTtii llHRy-nilBn-rr-K 

ConnectionManager::GetProtocolInfoO action a list of transfer protocols and data formats 
supported by the MediaRenderer is returned to the Control Point 

4. CompareflVlatch rrotocoi s/yamiats; The protocol/format uifomiation returned by tlie 
ContentDirectoiy for the desired Content Item is matched with the protocol/format information 
relumed by the MediaRenderer's GctProtocoIinfoQ action. The Control Point selectsa transfer 
protocol and data format that are supported by both the MediaServer and MediaRenderer. 

5- Conngure Server/Rcnderer; The device's CoimectionManagenrPreparePorConnectlonO action 
(if implemented) informs the MediaServer and MediaRenderer that an outgoing/incoming 
connection is obout to be mode using the specified transfer pioLocoI and data fumiat that was 
previously selected, Depending on the selected transfer protocol, either the MediaServer or 
MediaRenderer will return an AVTransport JnstancelD. This InstancelD is used in conjunction 
with the device's AVTransport Service (i.e. the device returning the AVTransport InstancelD) to 
control the flow of the content [e.g. Play. Stop, Pause, Seek, etc). Additionally, the Renderer will 
return a Rendering Control InstancelD that is used by the Control Point to control the Rendering 
characteristics of the content. 

Note: Sint» PrepareForConnectionQ is an optional action, there may be situations in which either 
the MediaServer and/or MediaRenderer do not implement PrepareForConnectionQ. When this 
occurs and neither MediaServer nor MediaRenderer return an AVTransport InstancelD, die 
Control Point uses an lnstancelD=U to control the tlow of the content Refer to the 
ConnectionManager and AVTransport Service Templates for details [?]. 

6. Select Desired Content: Using the AVTtansport service (whose InstancelD is renimed by either 
the Server or Renderer), invoke the SetAVTransportURIQ action to identify the content item that 
needs to be transferred. 
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7. ■ Start Content Transfer Using the A VTransport service, invoke, one of the transport control 

actions as desiredby the'user(elg/Play, Stop 

8. Adiusl Rendering Characteristics: Usjng the MediaRendarer's Rendering Cont^o^.scrvlot;, 
ifivbtce ahy;rendering control actipns as desired by. the user (e.g. adjust brightne:S5i contrast, 
vblume, mufs, etc). ' . ' ' 

9. Repeati Select Next Content;: Using either the AVTi-ansp6rt-:SetAVTTansportURIQ or 
AVTrahsport; :SetNextAOTRanispartIJRiQ^ actions,' ideptif/. the next content, item that 15. to:be. 
transferred ffom/ihe sairii; Scrvei to tiic-^wiw ' 

10. Cleanup Server/Renderer: When the session is terminated and MediaSerygr arid • 
MediaRenderer are no longer needed'in the cbiite^^^^ . 
M^diaRendefer'sCotuiectjbnMgr'rCopnectionGqiTip!^^^^ : 
MediaServ^r's connection, 

Based on the interaction sequertce shovvrt above, thefollowjng diasram chronologically iljustriates the 
typical interaction seqiience between the'' three Control .Spirit and the KdediaServeF and Tyied{iip:enderer. • 
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Playback: General Interaction Diag ram 
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6. Example Playback Scenarios 

As described above, Ihe A V Arcli Itecture is designed to suRportVbiLrary trananir praiocci'ls aiid data ; 
■ fprniats- Hdwever, m some cgses, certain devices are intentionally designed ro suppon a singl? transfer ' ' 
protocol arid/or dalaformat only-. For example, a'iTiani|facturer may want to deHver a product thattia^^^ 
particular price-point and/or murkfit segment Iii ihesB cases^ some AV de^^ices may combine' one or mc)f■ej.i'■ 
l&gical entitles mto asingle pliysical device. 

The following sub-septions illustrate the flexibility of Ihe gerieric Device jtlteraetion.jVlgci^t; algorithm. : : ' 
Pach of the following jiitci action diagrams arc:yariations of the generic ■dingram^ with^^ ■. ■ 

omitted These omitted steps arendt includedbecatise the particular scenano; does hof require them,. • ■ 1: 

6.1. Isoch ron ous-Pus h transfer Protocols (1EG61 883 / 
IEEE1394) 

When using an tsochrorious transfer protocol (e.g.IEC6I-8«3/ilEEEl394),. the underlying transfer. / ■ ■ ; ■ 
meohanjsm providea real-time content transfer betweieri the,Me'diaSerVer^iid;MediiLReri^^ TTiis eijs^fes 
thai individual packets of content are transferred within axertaln (reiatively.sraalI)pBnodciriihfie;- -T^^^ 
real-time behavior allows ihe MerfiaReriderer to provide the user viiidi sm.c>pthj-flo>ving renderihg of the. \: . . 
content -Without inlplementmg a read-ahead buffer:. In this envirqtimerjt, iJie fjpw of .the content is '. 
cpntrDlled by tiie MediaServet-.The MetfiaRendererTmrhediaielY^^ndersrth^ cQntent that ft reeBtyes firpni .• 
t^le■Med^aServe^. Referto the diagrahfi below fordetai^^ 
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Media 
Server 




Isochronous-Push 
requires Servsr (not 
Renderer) to return 
AVr InstanceiD. 
Renderer only returns 
an RCS InstanceiD. 



I Any AVT flow control 
operation, as nseded 
] (e.g. seek, stop, pause) 



Any RCS rendering 
control operation, as 
needed (e.g. volume, 
brightness, contrast) 



6.2. Asynchronous-Pull Transfer Protocols (e.g. HTTP GET) 

In this example, the transfer protocols that are used do not provide real-time guarantees. The arrival of a 
particular packet of content is unpredictable relative to the previous packets. Unless corrected, this causes 
the content to be rendered with certain undesirable anomalies {e.g. detectable latencies, jitter, etc.). In 
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order tp oompiensate for Ehese types of transfer mec Kan isiris, a Renderer device typically . implements a 
read-khead storage buffer in which 'the tenderer reads^aliead of tiie current output and places the da.ta.into 
a buffer lintit the.contents are needed. This allows the iVTedlaRenderer to smdoih out any rendering 
Anomalies thatniight otherwise • 
obligated to prbvide'lheJ.nstance of t^^^ 



© 1999. -2002 Microsoft Corporation. All Rights Reserved. 



UPnP AV Arcliitecture:0,83 



Control 
Point 



Media 
Renderer 



Asychronous-Pull 
requires Renderer 
{not Server) to return 
a AVT Instance! D. 
Server does notreturn 
an AVT InstancelD 
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6.3/ . No GM::Preparel=oi'ConnecttonO Act^^ 

In some circumstances, venilprs may cjiopse to pot iitiptement the PrepareForCohnecfion() action, winch ■. 
(among other tasks) provjdes a mechanistn for the Cpntrol Point to obtain, the'instancpIDof-lhe , 
AVTi^iispart and Rendering Contrpi Service to use for coiitrpl ling thB.flp\v anUrenderjngcharactenslics 
of 'the:cC)tlteht. When the P'repareFtirCbiiiit;ctiun(j. agllon is nGt:iniplcmontcd,.th.c Goritro! Point must foil' 
backvyd ass^irie'an Iristanceli>f(). TTie fdiimving digram illustrates liow lh&.^eneral Devic&lntprmTpn 
Mbdei-gracisfUlly scales to- handle this si^^^^ 
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Media 
Renderer 




- No AVr or RCS 
InslancetDs are 
relumed. 

- For AVT actions, use 
lnstancelD=0 on 
Renderer'sAVTflftt 
available). Otherwise 
use server's AVT. 

-For RCSacUons, 
USB lnstancefD=0 on 
Renderer's RCS. 



Any AVT flow controf 
operation, as needed 
I (e.g. seek.stop,pause) 



Any RCS rendering 
csonlrol operation, as 
needed (e.g. volume, 
brightness, contrast) 
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6.4. Rehderer Gpmbo Device using isdchronousTPush (e^g. 
rEEE-1394) 

Tiie fpllowing wEtmple illustrates h6\y:tbe general Deviee. Interaction. A Igonlhin is used to handie deyipes. 
that aisp include integrated Coiitro! Point 



Media Renderer, 
Media Control Point 
Server Cohribo Device 




.Control Point knows which 
protocols/formats are: . ■ 
supported by the (interna!) 
■Renderer device;. >. 



Randerar prepares itself to ; 
• ] receive the content 



Any AVT flow control 
operation.. as needed 
(9;g.-seek.stopipaiiS6) ■ 



J Any RCS rondonng control :. . 
operation, as needed"(e.g. . 
volume, brightness, contrast) ; 
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6.5. Render Combo Device using Asynchronous-Push (e.g. 
HTTP GET) 



Media Renderer, 
Control Point 
Combo Device 




Control Point knows which 
) protocols/formats are 
^ supported by tiie internal 
Renderer device. 



Asychronous/Pull requfres 
Renderer (not Server) to 
return an AVTransport 

InstancGlD. 



Renderer prepares itself to 
receive the desired content 
and starts/controls the flow of 
the content as directed by 
user, 



Rendering characteristics (e.g. 
volume, brightness) controlled 
intemaliy as direct by user. 



6.6. Server Combo Device using Asynchronous-Push (e.g. 
HTTP GET) 
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Contro) Point knows which 
prbtpcdte/formats are 
Vuppqrted by the internal 
Server device. 



JWfedia Server, 
ControlPoint Media 
Gombo Device . Renderer 



CM::GelPr9tocollnfoO,, 
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6.7. Server Combo Device using Isochronous-Push (e.g. lEEE- 
1394) 



Media Server, 
Control Point Media 
Combo Device Renderer 



Control Point knows which 
protocols/formats are 
supported by the internal 
Server device. 



Isochronous-Push requires 
Server to provide AVT 
InstancelD, so Renderer only 
returns an RCS InstancelD 



Server prepares itself to 
transmit the desired content 
and starts/controls the flow of 
the contont as directed by user 



Any RCS rendering 
control operation (e.g. 
SetBrightness) \ 
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6;$. Simpleist liitieraction Model Supported 



Media Renderer, 
Media Control Point 
Server Combo Device 




C Choose Matching - ^ 
Profodol and rormaty- 



j. ■CM:?PrBpareFbrCbnnertJori,0 ml 
I '. impfemented by eitberdevice ' '| . 



Control Point knows whicn 
prbtocols/farmats are 
supported by the internal , 
■Renderer device. " 




- No AVT or RGS fnstancelDsv 
areretumed. ■ 

^ For AVT. actions, use . 
lnstancelD=Q on Renderer's 
AVT (If it avgilablG). 
Ot}ierwise use Server's AVT. 

- For RCS actions, use 
lnstanceID=0 on Renderer's . 
RCS, • V . . • 



Renderer prepares- itself to ■ ■ 
receive the desired .contcnl 
and starts/controls the-flow of . 
the content as dtrected. by user 



Rendering characteristics' (e.g? 
volume, brightness) controlled 
:lnternal]y as dtrectby user. 



7. Recording Architecture 

the UPnP AV Aroliitecrure defines a ruJitneniarj^ R^uaidiiigcati.ability. A Kccoid autitin is dcrmcd. within 
the^iA^VTranport-SE,mceO. As content^^m being trartsferred from the MedipServer to the MediaRenderer. a' ' 
pontrtil Fointmay-fssu'e the .' Record* action. This results m the device 'recording', that content to some :-. - . 
type pruhspecifiied storage, The details of the Record feature depend completely on the recording devicee' 
BOid can; .range drsmatiDally from 
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